![[アップデート] Amazon FSx for NetApp ONTAPのMulti-AZファイルシステムをShared VPC上に作成できるようになりました #AWSreInvent](https://devio2023-media.developers.io/wp-content/uploads/2023/11/eyecatch_reinvent-2023-newservice-update.png)
[アップデート] Amazon FSx for NetApp ONTAPのMulti-AZファイルシステムをShared VPC上に作成できるようになりました #AWSreInvent
共有して使うものだからShared VPC上に作成したいけど、権限もできるだけ分離させたい
こんにちは、のんピ(@non____97)です。
皆さんはAmazon FSx for NetApp ONTAP(以降FSxN)をShared VPC上に作成したいなと思ったことはありますか? 私はあります。
FSxNはSMBの共有ファイルサーバーをはじめ、データを様々なプロトコルで提供するためのハブとして使われることが多いです。このような共有して使うリソースはShared VPC上に作成すると管理が楽だったりします。
Shared VPCを管理する組織と、データを管理する部門が異なるのは往々としてあります。
そのような場合、データ管理部門にその他の共有リソースが置かれているShared VPCのルーティングやサブネットの追加などの権限は与えたくないところです。IAMで頑張って制御するのも大変だったりします。
今回、アップデートでAmazon FSx for NetApp ONTAPのMulti-AZファイルシステムをShared VPC上に作成できるようになりました。ここでいうShared VPCはAWS Resource Access Manager(以降RAM)で共有されているVPCを指します。
AWS Blogsにも投稿されています。
何が嬉しいのか、もう少し深掘りしていきます。
何が嬉しい?
嬉しいポイントとしては、冒頭でも触れているとおり、ネットワークとストレージの権限分離がしやすくなったことにあります。
では、なぜMulti-AZファイルシステムのFSxNではそれが実現できなかったのでしょうか。
それはMulti-AZファイルシステムのFSxNの管理エンドポイントやNFSやSMBのエンドポイントはFloating IPアドレスで実装されているためです。
FSxNにおけるエンドポイントの説明は以下記事が分かりやすいかと思います。
そして、Floating IPアドレスのキモになるのは、「フェイルオーバーしたタイミングでサブネットのルートテーブルでFloating IPアドレスをスタンバイのENIにルーティングする」ところです。
このルートテーブルを変更するというのが従来ではできませんでした。
これはRAMでVPCを共有した時の仕様として、ルートテーブルを編集する権限を共有される側に渡すことができないためです。
Route tables
Participants cannot work with route tables (for example, create, delete, or associate route tables) in a shared VPC subnet. Participants can describe route tables in a shared VPC subnet.
Share your VPC with other accounts - Amazon Virtual Private Cloud
この制約によって、FSxN自身がフェイルオーバーしたタイミングで設定したルートテーブルのルートを書き換えるということができませんでした。
ルートテーブルを変更しないSingle-AZのファイルシステムの場合は、以前からShared VPC上に作成することができました。
ただし、高い可用性を求める上ではMulti-AZでデプロイすることが必須になることがほとんどかと思います。
このような「高可用性を求めたい」、「Shared VPCにFSxNを配置したい」、「Shared VPCがあるAWSアカウントに直接操作できる権限を持たせたくない」という場面に非常に刺さるアップデートだと思います。
どうやって設定するのか
設定は非常に簡単です。
Shared VPCがあるAWSアカウント上で、FSxNにおけるルートテーブルの更新を許可してあげれば良いだけです。
これにより、共有サブネットの関連づけられているルートテーブルを別アカウントのFSxNが変更できるようになります。
IAMでルートテーブルの細かい認可をするのは非常に骨が折れるので、このシンプルさはとてもありがたいです。
あとは従来通り、Shared VPC上のFSxNをデプロイ先のサブネットをRAMで共有し、共有された側はそのサブネット上にFSxNファイルシステムを作成するだけです。
注意点としては、前提としてRAMでサブネットを共有できるAWSアカウントは同じOrganizationsに所属しているもののみです。別OrganizationsのAWSアカウント間では、そもそもサブネットは共有できないため注意しましょう。
どのリソースが、どのような条件で共有できるかは以下AWS公式ドキュメントに記載されています。
Amazon FSx for NetApp ONTAPのMulti-AZファイルシステムを良い感じに共有してくれる機能ではないので注意
Amazon FSx for NetApp ONTAPのMulti-AZファイルシステムをShared VPC上に作成できるようになりました。
これによりロールに応じた権限分離が捗りそうです。
なお、このアップデートを始めて見たときは「Transit Gatewayを使わずに魔法の力で別VPCからアクセスできるようになったのか!?」と勘違いをしてしまいました。
皆さんはre:Inventでテンションが上がりすぎて早合点しないように気をつけてください。
この記事が誰かの助けになれば幸いです。
以上、AWS事業本部 コンサルティング部の のんピ(@non____97)でした!
![[Amazon FSx for NetApp ONTAP] SMBでファイルオープン中にフェイルオーバーが発生した場合の挙動を確認してみた](https://images.ctfassets.net/ct0aopd36mqt/wp-thumbnail-9e9d102dfa6d7896319b16fe069cdf55/c3bbbeab42ba5764c5a573e979719805/amazon-fsx-for-netapp-ontap)
